The communications protocol used in a typical mainframe environment maintains state information about each user's session. A session is an active connection between two computers. For example, a user begins a session when the user logs into and is authorized by a mainframe computer from a workstation.
Communication between the user's workstation and the mainframe is maintained during the session. Every time the user communicates with the mainframe, the mainframe must confirm who the user is and whether the user is currently logged-on. The communications protocol used between the mainframe and the user's workstation facilitates this session-state tracking.
Identification, validation, and authorization are main reasons for tracking a user's session state information. The mainframe identifies the user.
If the identified user is already logged-on, the user is validated. It is not desirable to force a validated user to logon each time there is any communication. Other than being frustrating, this would be extremely inefficient. Once the user has been identified and the user's logon is validated, the mainframe manages her access to available resources.
Typically, users are not authorized to have access to all available resources. Instead, each user is given authorization to access a specific set of resources. Maintaining readily available session-state information makes it easy to identify, validate, and authorize users.
Part of the core problem with all of session-state management techniques is identifying the user. One way to identify the user is to employ the unique address of the client computer that the user is using. Another way is to use a unique user identification indicator (UserID). The unique UserID is a popular choice because it is personal, reliable, and portable. Using the “unique” address of a client computer is often not a desirable option because, depending on the exact network configuration, the address might not be personal, it might not always be unique, and might not be portable.
The universal session-state management issues include:                User Identification—Who is the user, and is the user really who she claims to be?        Logon Validation—Is the user currently logged on?        Logon Expiration—How long has it been since last contact with the user?Session-state information identifies the user and validates that the user is currently logged-on. Session-state information is tracked during a session.        
A session begins when the user first contacts the server. User authentication is the first task in the session. Typically, a user provides a user name and a password. If the user name and password match accordingly in the authentication database, then a user begins a session and session-state tracking is initiated.
In addition to user identification and logon validation, it is often desirable to track the last time this particular user was active. The system may be programmed to automatically disconnect a user if there has been no activity for a specified time block. This is called “time-out” or “logon expiration.”
Logon expiration is optional. However, most systems utilize some sort of session time-out tracking. This is particularly true in communications networks that employ communications protocols that do not inherently track session-state information. These networks are called “stateless” Most asynchronous communications networks are stateless.
Stateless networks have no mechanism for monitoring the state of a user's session. They can only gauge a user's desire to maintain a session by active communications from the user. A stateless network cannot determine if the user has turned off their computer and gone home for the day. In other words, a user of a stateless network can discontinue use without “logging-off.”
Time-out is the mechanism utilized to automatically “log-off” a user after a given period of inactivity. Typically, a user-associated record is kept that indicates the last time there was contact from the user. If the “time-out” time block passes between user activities, then the user is timed-out. If she returns, the user is forced to logon again.
Reasons for session time-out include security and releasing of resources. The time-out feature adds security by making it less likely for someone to impersonate another by using the other's computer. Session timeout also facilitates the release of resources allocated to the user during their session so that such resources can be used by others.
Other user-related information can be tracked as session-state information, such as the contents of an electronic “shopping cart,” purchase history, personalization factors, and the like. However, these are not as vital for security and identification as are the universal session-state management issues.
Limited-access sites on the World Wide Web (“Web”) have introduced the need for tracking session states over the Internet. This is particularly true in the realm of Internet commerce, which is also called “e-commerce”, “e-business”, “on-line business”, “Web-business”, and the like. It is vitally important that an e-business Web site have a reliable mechanism in place for users to establish and maintain a session.
However, the communications protocol that is typically used with the Web is stateless. Standard Web protocols (such as Hyper Text Transfer Protocol “HTTP”) can be thought of as a request/response pair. That is, a client or user makes a request that is filled by a server. After the request/response is complete, a Web server, cannot tell if a user intends to make further requests. Thus, in secure sites, a server cannot tell if a user is still logged in; has moved on to other sites, or has turned off the computer and gone home.
In stateless protocols, with each communication, the Web server must check on the state of the user's session. Since the protocol does not assist with this, techniques have been developed to accomplish session-state checks. These techniques typically involve saving state information somewhere and examining that information with each exchange.
FIG. 1 shows an example of a typical e-commerce network configuration 100. In order to track the session state information of the user, a typical Internet configuration includes three session-state storage tiers 102, 104, and 106. At 102, session-state storage tier 1 includes a client 110. The client 110 is a computer (such as a laptop, desktop, or special purpose Internet device) that is capable of running a Web browser. An example of a Web browser is “Internet Explorer” from Microsoft Corporation. The client 110 is connected via its Internet Service Provider (ISP) 112 to the Internet 114.
At 104, session-state storage tier B includes one or more Web servers 120 connected to the Internet 114. At 106, session-state storage tier C includes a Web 11 database 130 connected to the Web servers 120. Session-state information can be stored at any one of, or any combination of, these three tiers. Each option or combination of options has drawbacks and limitations, such as scalability, reliability, resource efficiency, loss of centralized control, and security.
Tier A (Storing on the client): The Web server 120 may pass session state information to the client 110 for the client to store locally. The information is stored within tier A. Each time the client sends info to the Web server, it passes along the stored session-state information. The server updates the information and passes it back to the client. This exchange can be accomplished using hidden form fields, universal resource locators (URLs), cookies, or other similar techniques. Those who are skilled in the art are familiar with the available techniques to exchange administrative information between a Web server and a Web browser.
The disadvantages of storing session-state information at Tier A include: lack of speed, inefficiency, unreliability, and lack of security. This technique generates a large amount of administrative data that is flowing back and forth with each communication. In addition, the Web browser must send all session data on each request to enable the Web server to get the session-state information. This reduces the effective communications speed and efficiency.
This technique is unreliable and unsecure because the user's session-state information is stored outside of the control of the Web server. Since it is stored with the client, the Web server must trust the information that it receives. However, the information that the server receives can be accidentally incorrect (because of data corruption on the client) or it can be purposefully incorrect (because of an attempted security violation).
To avoid security disasters where users masquerade as other users, many of these Tier A techniques encrypt the session-state information. To be more specific, they use two-way encryption schemes, which are schemes where encrypted information can be easily recovered by decryption. A server encrypts session-state information and passes it to the browser. The browser stores it and returns it to the server upon subsequent communications, where it is decrypted, used, and updated by the server before being re-encrypted and returned to the client. This again adds to the overhead and inefficiency.
Although encryption makes a security attack less likely, it does not eliminate it. Since these techniques require the use of two-way encryption, the browser-stored, session-state information can be decrypted. The door may be locked, but it is not sealed.
Tier B (Storing on the Web server): To eliminate the need to encrypt and decrypt the session-state information with each request, the Web server 120 may simply store all session-state information at the Web server itself. The information is stored within Tier B 104. This is the easiest session-state information storage solution.
The major drawback to this technique is scalability. E-commerce Web sites are generally hosted by a family of Web servers that work together to balance the load. This balance is accomplished by gatekeepers called “load balancers.” This family of Web servers with a load balancer is often referred to as a “Web farm.”
Load balancers typically work by passing an incoming request to any server that is available to process it. Thus, different Web servers in the farm may service subsequent requests from the same user.
If session-state information stored at Tier B (on the Web servers), then each server must have access to the session-state information of each currently logged-in user. This is because any server may receive a request from any server at any time. Therefore, the servers must be able to communicate with each other and share session-state information.
With session-state information storage in Tier B, each server must maintain a copy of session-state information for all users. Alternatively, groups of servers can service designated groups of users. Therefore, all servers within a given group must maintain a copy of the session-state information for their designed users.
The copies of the users' session-state information are updated whenever that information changes. This communication overhead and storage of redundant information is inefficient. These inefficiencies are not terribly great when dealing with one or two Web servers. However, this overhead can severely impact the performance of a Web site when a Web farm includes more than a few servers. Therefore, this technique fails as the scale increases.
Tier C (Storing on the Web database): To overcome the inefficiencies of a Tier B solution, a central database may be to store information once. The Web database 130 stores all session-state information for all of the Web servers of the farm to access as needed.
Using a centralized database ameliorates the scalability problem, but it does not eliminate it. In order to handle increases in workload, the Web database must grow with the Web farm to support the management of additional session-state information of new users.
Presently, storing session-state information in Tier C (on the Web database 130) is the most common approach to solving the problems of tracking users' session-state information over the Web. FIG. 1 shows an example of this approach. The Web database 130 stores a user's universal session-state information in block 140. This block 140 includes “user identification” 142, “current logon status” 144, and “time of last contact” 146.
Available Tier C techniques of tracking session-state information in Web farms rely on either database-based sessions, queries against a LDAP (Lightweight Directory Access Protocol) service, or an in-memory session state. All of these back-end services running on a Web database will bottleneck as more servers are added to the farm in order to scale. The database or LDAP services on the backend will need to be scaled as the servers scale, and can become very expensive and complex to maintain. Additionally, the request from each Web server to a Tier C service introduces latency and delays to the response to a user's request.
Although session-state management techniques exist for use over stateless communications networks (such as the Web), each has drawbacks and limitations. Many address the universal session-state issues of user identification, logon validation, and timeout. A common characteristic of the popular techniques is storing the session-state information at one or more of three tiers (102, 104, and 106 of FIG. 1). Storing session-state information at any of the tiers impacts scalability, speed, efficiency, reliability, or security.